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FORTRAN AUTOMATED CODE EVALUATION SYSTEM 


USER'S MANUAL 


I. FACES OBJECTIVES 

The FACES system provides analysis services for FORTRAN 
based software systems not normally available from system software. 

i 

FACES is not a compiler; compiler syntax diagnostics are not dup- 
licated. For maximum adaptation to FORTRAN dialects, the code pre- 
sented to FACES is assumed to be compiler acceptable. 

The FACES system concentrates on acceptable FORTRAN code 
features which are likely to produce undesirable results. Emphasis 
is placed in the following areas: 

1. Interface integrity among modules, 

2. Misleading code subject to maintenance problems. 

3. Keypunch errors likely to escape the compilation process. 

4. potentially malformed execution sequences. 

5. Use of compiler sensitive code. 

The purpose of FACES analysis is to identify potential trouble 
areas before they become execution time malfunctions. 

While many messages indicate solid errors, messages are pro- 
vided primarily to motivate user inspection of suspicious code. 
Messages should be evaluated by the criteria,’ 

1. Do I understand how the mechanism works? 

2. Is the feature sufficiently documented by comments or in 


the system documentation? 
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3. Would this feature confuse maintenance personnel? 

4. Can a set of data values cause an error 1n execution? 

5. Would a simple change improve code clarity? 

Code features should be examined for suitability as well as "will 
it work". 

The FACES user is assumed to be conversant with FORTRAN but 
at a disadvantage with code bulk and peculiarities of the FORTRAN 
language. FACES attempts to inform the user fully as possible 
what is being found as well as status information on system operation. 
It is the user's responsibility, however, to distinguish error poten- 
tial from superficial differences in expression. Maximum advantage 
is gained by directing the user's intelligence to program areas most 
likely to cause problems, 
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n. OVERVIEW OF SYSTEM OPERATION 

FACES, is Intended for application to FORTRAN based software 
systems composed of moderate to large number of modules. Modules 
usually become available for analysis in groups over a period of 
time. FACES is designed to incorporate new modules into the system 
as they become available. 

In general, previously submitted modules are considered stable 
components. That is, once analyzed! the modules usually remain un- 
changed. 

In practice, however, occassional ly need arises to modify an 
existing module. Rudimentary capabilities exist for replacing modules 
in the system; FACES is not, however, a general purpose file manage- 
ment system. 

Anticipated operating environment . Software modules should be 
compiled and preferably unit' tested prior to submission to the FACES 
system. That is, the programmer should have some level of confidence 
in the software. 

The first set of modules presented causes a library of modules 
to be created. The library consists of module source code and 

< 

various analysis tables which characterize the code. As new modules 

♦ 

become available, ’ they are analyzed,and incorporated with previous 
software modules. 

The existing modules of the software system can be analyzed 
by selecting inspection criteria, called queries , to be applied to 
the software system. Queries may be selected either while adding 
new source or on independent runs. 
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After analizing the inodul'^s for npedfied constructions the 
user can request a report . Reports are annotated program listings, 
truncate- listing, and displays of data extracted from the software 
system. 

The major reporting vehicle is the primary report . The 
primary report is an annotated module listing similar to a compiler 
listing with analysis messages attached to source lines where 
detected conditions were found. 

Many problems are apparent only by considering multiple modules 
or portions of a single module. Secondary listings extract and 

I • 

display source lines from several modules or portions of a module 
on a single listing. For example, if a COMMON block problem is de- 
tected, considering all problems with a single block usually yields 
a better solution. Secondary listings minimize page flipping among 
various modules and hand tracing of control paths when evaluating 
report results. 

The third report form is the display* repor t. Display reports 
are organized data extracted from the software system. They differ 
from secondary listings in that source code is not extracted for 
display. 

Summary of Internal Operation . FACES is roughly organized 
into a driver section with three subsystem components. The main 
driver is responsible for fil^ manipulations and interpreting user 
commands. The subsystems are; 


y I I i I 1 i 

a 

II. 3 

« 

!• FORTRAN Front End (FFE). The FFE analyzes submitted source 
code and constructs tables which characterize module operation, New 
modules and references to other modules are inserted in a module Oirec 
tory for system use. Source code of submitted modules is captured on 
a Source Code Catalogue file for use In generating reports. Situa- 
tions which limit processing effectiveness are recorded on the Flag 
file. 

2. Automatic Interrogation Routine (AIR). AIR examines the 
tables generated by the FFE for the constructions selected by the 
user. If the specified constructions are found, diagnostic messages 
are recorded on the Flag file. 

Report Generator . The Report Generator combines the contents 
of the Flag file with the module source code to produce user reports. 


Phased operation . Due to unavailable system services, the 
FACES system is implemented in three phases. The three phases are 
identical to the three sybsystems: FFE, AIR, and Report Generator. 
Implementation in phases restricts manipulations and reports 
available during a single run, but does not reduce analytic capa- 
city. 
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in. CAPABILITIES 

The user controls FACES operation through coniniand cards. 

Commands cause new source to be added to the software system under 
analysis, Investigations to be selected, and results reports to be 
generated. 

Module Directory . To catalogue the software system under 
analysis, a directory is maintained by FACES. Entries of the 
directory are all modules submitted for analysis and all references 
to other modules not yet defined. The directory also maintains 
pointers to file entries for module analysis table access and 
retrieval of source code. 

As modules are added to the system,, undefined directory entries 
become defined and the source code is considered in the analysis. 

The user controls directory entries by controlling modules submitted 
to the system. 

Report s. The three report types are» 

1. Primary l isting reports . Annotated listing of modules. 

2. Secmdary listing reports . Truncated listing of source 
code participating in a query message. 

3. Display reports . Displays of data extracted from the 

software system under analysis. 

1 

The Primary listing report contains both query analysis results 
and FORTRAN diagnostics issued for modules added to the system. The 
user controls primary reports through the REPORT command and indirectly 
through query selection. Default options produce reports only for 
modules to which messages are to be attached. 
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Secondary listing reports arc ordins;^ily supplemental to the 
information on the primary report. Secondary reports may be sup- 
pressed through query selection. Alternatively, the secondary 
report can be produced in lieu of primary report messages. 

Display reports are produced only if queries are selected 
which generate reports in the display form. 

Principal user l 6 <trol of messages is through the query 
number. Each query message contains a numeric field indicating 
the query number which generated the message. The message may be 
turned off by excluding the query from the analysis list of sub- 
sequent runs. 

FORTRAN Front End messages appearing on the listing cannot 
be controlled. They appear only when the module is analyzed for 
incorporation in the system. 

Command Cards 

Syntax . Command cards an? free format single card images of 
80 columns. Command items on the card are order dependent character 
strings terminated by a blank or a special symbol. 

Blanks are separators in command card fields. Several blanks 
are equivalent to a single blank. Therefore, the character string 
AB is a single element, while A B are two separate elements. 

Command items are alphanumeric symbols classified as: 

1 . Command key words 

2. User specification controls 
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The general format for command cards Is, 

Key word ^ Option list 

where: Key, word Is an alphanumeric charater string without 
'' Imbedded blanks. 

^ Is one or more blank columns. 

Option list Is a command relative list of options 
with specific defaults. 

Available Commands . The following Is a description of commands 
for controlling FACES operation; 

INITIAL System . The INITIAL System command causes a • 
new software system to be created for analysis. The card format Is, 

INITIAL SYSTEM 

v/here SYSTEM Is an optional entry In the command 
The INITIAL command clears the module Directory, Source Code 
Catalogue, and Table File. 

WARNING ; The INITIAL card should be used only once to create 
a software system. Use of this card after the first run will cause 
previously created data to be destroyed. 

ADD Source . The ADD source card causes new modules to 
be incorporated In the analysis files. The card format Is, 

ADD SOURCE 

where SOURCE is an optional entry 
The ADD command causes source code modules to be processed and added 
to the analysis files. New source code Is added to the Source Code 
Catalogue. New modules participate in analysis as soon as they are 
added. 
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If a new module name Is an existing Directory entry > 
the new module replaces the previous module, A message is Issued 
to inform the user of these replacements. File space is not re- 
covered on replacement, 

QUERY . The QUERY command causes a software system to be 
examined for specific features, Queries are indentified by number 
♦ (see Table I). A query list is specified by a sequence of 

query numbers separated by commas. For example, the construction 
110,120,411, 190 specifies queries ANSIST, RESWRD, CBTYPE, UNINT. 
Blanks may appear between elements of the list. Numerical order is 
not required. The list is terminated by the absence of a comma. 

QUERY commands have two forms: 

Predefined QUERY group 

QUERY group exceptions 

where: group is an establirbed category of queries 

ALL (default) - examine all moaules for all features 
LOCAL - only queries which treat Internal construc- 
tions of a module are selected, 

GLOBAL - only queries which examine module inter- 
faces are selected. 

exceptions are an optional list of queries to be ex- 
cluded from the group. 
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GROUP 

6 





L 

L 





0 

0 


QUERY 

QUERY 

A 

C 

B 




L 

A 

A 


NUMBER 

NAME 

L 

L 

L 

Purpose 

no 

ANSIST 

X 

X 


Detect misleading use of ANSI Standard 


% 




function names. 

120 

RESWRD 

X 

X 


Detect misleading use of FORTRAN ’Reserved' 






words, 

130 

DATVAR 

X 

X 


Detect COMMON variables set by DATA 

statements outside BLOCK DATA. 

< » 

140 

FLINPAR 

X 

X 


Detect FUNCTIONS which modify parameters. 

150 

MULBRA 

X 

X 


Detect multiple branch statements which 
do not lead to next statement. 

160 

REDLOP 

X 

X 


Detect redefinition of DO loop control 
parameters. 

170 • 

DOTERM 

X 

X 


Detect use of DO loop control index after 
loop termination. 

171 

DOTERM 

X 

X 


Show paths using control index after 
termination. 

180 

ASNUSE 

X 

X 


Detect local variables assigned values but 
not used {possible keypunch error). 

190 

UNINT* 




Detect uses of uninitialized local variables 
(possible keypunch error). 

191 

UN I NT* 




Show path of uninitialized use. 

400 

CBNENT 

X 


X 

Detect COMMON blocks with different , 
number of. entries. 
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401 

CBNENT 

X 

X 

Show COMMON blocks with different number 
of entries on a single listing. 

410 

CBTYPE 

X 

X 

Detect COMMON blocks with entries having 
different type. 

411 

CBTYPE 

X 

X 

Show COMMON blocks with type variations 
on a single listing. 

420 

CBDIM 

X. 

X 

Detect COMMON blocks with entries having 
different dimensions. 

421 

CBDIM 

•“X 

X 

Show COMMON blocks with dimension variations 
on a single Msting. 

430 . 

CBONE 

X 

X 

Detect COMMON blocks attached to only one ■ 
module (possible keypunch error on label). 

440 

CBNAME 

X 

X 

Detect COMMON blocks with different names 
in corresponding entries. 

441 

CBNAME 

X 

X 

Show COMMON blocks having different entry 
names on a single listing. 

450 

CBINDS 

X 

X 

Detect COMMON^blocks with entries having 
different sizes. 

451 

CBINDS 

X 

X 

Show COMMON blocks with different sized 
entries on -a single listing. 

460 

CBTOTS 

X 

X 

Detect COMMON blocks of different total size. 

461 

CBTOTS 

X 

X 

Show COMMON blocks of different sizes on a. 
single listing. 

500 

PLNENT 

X 

X 

Detect parameter lists having a different 
number of parameters. 

501 

PLNENT 

X 

X 

Show calls and module definition for dif- 
fering parameter lists. 
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III 


510 PLTYPE X 

511 PLTYPE X 

520 PLDIM X 

521 PLDIM X 

600 CYCALL X 


X Detect parameter lists with different 
types passed. 

X Show CALLS and module definition for 
type differing parameter lists. 

X .Detect parameter list entries with 
incoinpa table, dimensions. 

I 

X Show 'CALLS and module definition 

for dimension incompatable parameters. 

X Detect potential cyclic calling patterns 
among routines. 


^available only through QUERY ONLY option 
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^ EXCEPT " qufery list 

The specified queries are to be exploded from 

! 

the group. 

(default) - no exceptions 


EXAMPLES 

QUERY ALL all queries are applied to the 

> 

QUERY J software system 

QUERY LOCAL EXt TT=120,171 

Perform all local queries except RESVIRD. 

Do not generate path listing for DO loop index variable 
used after loop terminated normally. 


QUERY GLOBAL EXCEPT=401,460 

Perform all global queries. COMMON blocks with 
different number of entries will not be produced 
as a separate listing. COMMON blocks with dif- 
ferent sizes v/ill be indicated only in a sepa- 
rate listing. 


User defined QUERY group 
QUERY 0NLY= query list 

where query list is a user defined group of queries to be 
performed. 

The queries specified in the query list are executed in the 
order specified by the user. Although numerical order is not required, 
maximum' processing speed results from ordered query lists, ^ 
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EXAMPLES 

. QUERY ONLY= 501, 140, 171 ' 

Causes a separate listing for parameters lists which have a 
different number of entries, primary listing messages for functions 
which modify their parameters, and paths displayed where 00 loop 
control variables are used after normal termination, 

REPORT . The REPORT command causes analysis to be displayed. 

The REPORT command has the form: 

REPORT option 

where option controVs primary listing reports: 

ALL “ print listing of all modules in the software 
■ system being analyzed. 

FLAGGED (default) - print listings for only the 
modules v/ith attached messages. 

Secondary reports of separate listings are not affected by 
the option selected. 

Secondary reports are generated if sfelected query analysis 
produces secondary results. If no report'is requested, a default 
flagged report is generated. 

After a report has been processed, the analysis Flag file is 
set empty. 

Abbreviations on commands . To minimize keypunch and spellipg 
.errors, only the first character of key words are considered 
in determining the command. (Note: Since the INITIAL command poses 
special jeopardy in the system, INITIAL command cards must contain 
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all alphabetic characters.' Abbreviations accepted are as follows; 


I - INITIAL 

A - ADO source 

Q - QUERY 

R - REPORT 

A - ALL 

A - ALL 

L - LOCAL 

F - FLAGGED 

G - GLOBAL 


E - EXCEPT 


0 - ONLY 



Command card order . 

The INITIAL System command must be the first command card 

if a new software system is being established. For operation in 

phases, the following sequence is required in command cards; 

* » 

PHASE 1 - INITIAL System (only for first run) 
all ADO Source commands 
PHASE 2 - atl QUERY commands 
PHASE 3 - REPORT command 

/ 

If a particular command is not required on a run the command 
cards can be omitted. The processing phase for that command set 
will perform a "no-op" in this situation. For example, if no source 
code is to be added for an existing software system, QUERY and REPORT 
cards can be used to generate reports. PHASE 1 will perform no ac- 
tions in this event. 
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A ppendix A 

Acceptabi e FORTRAN Code 

Any dialect of FORTRAN may be presented to FACES although 
certain machine dependent forms will be excluded from the analysis. 
Input source code to FACES is expected to be largely ANSI Standard 
constructions. Commonly accepted dialectal extensions of the stan- 
dard are included. If unrecognized machine dependent code ii present, 
portions of the statement text will not participate in the analysis. 

'A diagnostic will be issued to indicate lines of code not included 
in the analysis. 

Input source code is assumed to be compile error free. Very 
I'mited syntax checking is performed by FACES. If a syntax error occurs 
which limits statement processing, the statement is truncated at the 
error position. In some instances, error recovery is possible; the poor 
ly formed or .unrecognized section will be skipped. 

Syntax diagnostics are produced only on the run in which the 
source code Vs added to the system. 

% I • 

Sumiiiarv' oF Processed Constructions . The following description . 
is a brief review of FORTRAN constructions processed by FACES, A 
description of detailed constructions is presented in Appendix D. 

1. Character set . 

blank character (significant only in literals) 
alphabetic Una. ccters A-Z 
numeric characters 0-9 
special characters = + - * / , ( ) . $ ' " 

* 
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2. Card format . ANSI standard format. 

3. Continuation cards . ANSI standard format, 

4. Comment cards . Any character other than blank or a number 

in column 1 causes the card to be treated as a comment. 

Blank cards are comments. 

' , 

Symboli c^ names . Bight character or less beginning with 
an alphabetic character. 

6. Data types . Extended ANSI standard type definition. 
Logical 
Integer 
Real 

Double Precision 
Compl ex 

Hollerith - literal constants only 
Neutral - Statement labels, Subroutine 

names, Common block labels, etc. 


^ Extended 
Type 


V ANSI standard 


7. Constants. 


Integer 
Real 

Double Precision 
Complex - mixed precision permitted 


ANSI standard forms 


Logical - .TRUE. .T. .FALSE. .F. 
Literal - wH char string 
* char string ' 

“ char string 
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Nondcciinal base constants - wZ hex chars 
0. Program variables . Variable names are limited to 8 
characters or less and muU begin with an alphabetic 
character. Array dimensions are not restricted in number. 
Subscript references may be any arithmetic expression. _ 

9. Operators . 

Arithmetic operators +-/*** 

Logical operators .NOT. .N. .AND. .A, .OR. .,0. 
Relational operators .EQ. .NE, .GT. ,GE, ,LE. .LT. 

10. Arithmetic expressions may contain either logical or 
aritlimstic operators. 

11. Branch targets may be either statement labels or variables 
set by ASSIGN statements. 

Summary of Processed FORTRAN Statements . The f ol 1 owi ng des- 
cription is a brief summary of FORTRAN statements currently pro- 


cessed by FACES. A detailed description of allowable syntax 

presented in Appendix D. 


1. Module ’header card. 

PROGRAM 

type FUNCTION 

BLOCK DATA 

SUBROUTINE 

2. Data declarations. 

DIMENSION 

IMPLICIT EQUIVALENCE 

INTEGER 

COMPLEX DOUBLE PRECISION 

LOGICAL 

REAL COMMON 


DATA 


EXTERNAL 
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Control statements , 

GO TO (unconditional, assigned, and computed) 

ASSIGN 

IF ( 3 branch arithmetic, 2 branch logical, and 
conditional statement execution) 

DO 

CONTINUE PAUSE STOP END 

4, Assignment statements . 

5, Input/Output statements . 

READ WRITE PRINT PUNCH 

END FILE REWIND BACKSPACE 

6, Subprocess statements . 

ENTRY Statement Function definitions 

CALL Function References 

RETURN EXTERNAL 

Excluded Statements . The following statement forms are ex- 
cluded from processing. 

1, FORMAT . Information from FORMAT statements is not re- 
quired for current processing. The presence of FORfiATs 
produces no diagnostic message or loss of capability. 

2- NAMELIST . NAMESLIST forms vary among FORTRAN dialects. 

A NAMELIST statement is recognized but the variables 
specified are not processed. A diagnostic is issued to 
inform the user of omissions in the processing. 

/ 
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3. ENCODF./ DECODE . These statement forms and operational 
requirements differ among FORTRAN dialects, ENCODE and 
DECODE statements are recognized but not processed, 

Variables specified In ENCODE and DECODE statements do not 
participate In the analysis. 

Required order for FORTRAN source code . FACES Is designed 
to minimize deck modifications in submitting code for analysis. 

The basic requirement Is that all modules begin v/lth a module 
header card (e.g. PROGRAM, SUBROUTINE, FUNCTION, and BLOCK DATA) 
and end with an END card. Array declarations must appear prior 
to the first executable use of an array element. Statement func- 
tion declarations are not constrained. Internal order of other 
statements Is not significant. 

Some FORTRANs default the main program to a module not 
Identified as a subprogram. In this case, a PROGRAM card must 
be Inserted to identify the module in the Directory. This mechanism 
was selected to prevent a spurious line of source code between 
modules from being 'Identified as a "new" main program, replacing 
valid analysis data for the actual main program. 

For user convenience, Comment cards are permitted between 
decks. These cards are associated with the next module defined 
for the softv/are system. Comment text 1s ignored 1n the analysis. 

i 

Since modules are Identified by name, only one BLOCK DATA ; 

i 

may be submitted for a softv/are system. If multiple BLOCK DATA 
routines are presented, the last deck encountered is used in analysis. 

. t 
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FACES diagnostic messages are not necessarily prograiiming 
errors; rather, they indicate code sections which merit inspection. 
The investigations should include consideration of the following 
aspects: 

1 • Vulnerability to Compiler Interpretation . ANSI Standard 
forms are not "perfect code", however the standard con- 
structibns define precise operations whinh must be imple- 
mented by compiler authors. Variant forms are selected at 
the compiler writer's option for implementation , If un- 
specified compiler features are used in the program, there 
is no guarantee the next version of the compiler v/ill comply 
with current techniques. Compiler diagnostics are usually 
not generated when these changes are made. 

As a minimum, the code used for system implementation 
should conform to concrete operations specified in the 
FORTRAN user's manual. If the code will be transported to 
another system, only ANSI Standard forms should be employed. 

Techniques which enhance execution speed of generated 
code, called "optimization", may produce undesired and sur- 
prising results in execution. The progranmer must be wary 
of certain hazardous techniques if optimization is used in 
the compiler. 

2. Potential Misinterpretation . Program operation is almost 
always clear to the author in the beginning. To a second 
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party, style and uniformity are as important to compre- 
hension as algorithm completeness. Hidden variations in form 
are invitations to future failure during maintenance and 
modification. 

3* Implementation Errors . Even thoroughly tested code is 
subject to implementation errors. Often, the "right" test 
case has not yet been encountered. Keypunch and coding 
errors frequently produce valid FORTRAN code. These problems 
are more quickly surfaced if "unusual" coding patterns are 
displayed for user inspection. 

4. Interface Fumbles . Interface consistency reduces chances of 
incorrect operation. Since module interface checks are ' 
difficult to verify manually, unusual interface operations 
are indicated by FACES analysis. 

5. Runtime Linkage . Operations among modules in the normal 

■ compne/1 ink/ load mode are not precisely defined by the ANSI 
Standard. Many surprises await large software systems with 
imperfect calling protocalls. Little diagnostic information 
on module linkage error is provided by computer support soft- 
ware. 

Path Tracing . FACES does not consider program logic in path 
tracing, hence "impossible" paths may be produced. When considering 
these paths, the user should be av/are that "impossible" conditions may 
become "possible" in error environments or in the expanded scope of 
future modifications. The cost of a few additional assignment statements 
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or extra tests must be cbrefully weighed against the cost of 
potential future malfunctions. 

Individual Query Considerations . The following discussion is 
intended to assist the user in the evaluation of malfunction potential 
as indicated by messages, 

110 - ANSIST - The use of an AIISI Standard function name as a program 
variable may mislead maintenance personnel. The potential 
for misinterpretation is especially high if the variable is 
subscripted. 

The use of an ANSI Standard function name as a software 
module name is both misleading and dangerous. If another 
module attempts to use the standard function, linkage will 
normally be generated to this software module. Thus, the 
use of this name will exclude the use of the standard function 
in the system. 

Defining a function with the same name as an ANSI Stan- 
dard name is even more problematic, In some compilers, many 
standard functions are effectively compiled "ln-1ine“ — no 
linkage is created to external modules. As, a result, the 
code will evaluate the standard function rather than call the 
user's routine. 

If optimization is performed by the compiler, the 
user's routine reference may be mistaken for a reference to 
the standard function. This may result in the optimization 
creating incorrect code. 


B. 


120 - RESWRO - Usy of FORTRAN "»'Rr»crvod" words iiiuf os code 

difficult to read. Hov/ would you like to follow code like: 

I 

DO ir(K) (an assignment statement). 

130 - DATVAR - Data statements to COMMON variables In routines other 
than BLOCK DATA are contrary to the ANSI Standard, If this 
restriction 1s intended to protect the user from Initializing 
the same variable more than once. Multiple Initializations 
make program operation "load dependent" (I.e., the Initial 
value is set by the last module loaded). 

If the system Is required to operate In an overlay 
fashion, DATA statements may reinitialize the COMMON, variable 
on each overlay; alternatively, the variable may not be re- 
initialized each time. Exact operation is machine dependent, 
BLOCK DATA, however, is usually loaded once. 

140 - FUNPAR - Functions which modify their parameters can lead to 
unexpected results. Since the ot ‘-put from a function is 
through the function name, programmers are less cautious 
of parameter side effects. Input parameters to functions 
are frequently constants; modification of a constant may 
upset the calling routine. Since the error occurs on the 
other side of an interface, this error is particularly 
■difficult to find. 

For example, 
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Y = FUNC(2., X*3) 

* 

;\ 

FUNCTION FUNC(A. .B) 

A " A**2 (2. Is now the value 

Who would expect 2. to suddenly change value? 

Another problem with side effect functions occurs if 
compiler optimization is performed. If an expression, for 
example X*3, is changed, a bad value may be passed to a 
later computation containing the "common subexpression" X*3. 

Since functions may appear in IF statement conditions, 
compilers may not execute the function as often as the user 
expects. Some logical conditions are compiled to branch as 
soon as a .TRUE, or /FALSE, value is determined; if the 
function appears several times in the logical expression, 
the function may only be referenced once. For example, con- • 
sider, 

IF( FUNC(I) .OR. FUNC{J) ) B = C 


If the first FUNC reference produces .TRUE. , the second 
reference may not occur at all. 

150 - MULBRA - Multiple branching statements which do not branch to 
the statement immediately following, are necessarily errors. 
There is a strong chance the branch list .is incorrect. If 
correct, this type of branch is rather unusual and may re- 
present a "special case" or code "patch" to be removed in 
the future. 


4 


I 


1 


i 


B. 6 

160 - REDLOP - The redefinition of DO loop control variables 

within the loop body violates the ANSI Standard. Loop 
operation is usually unpredictable. At the very least, 
this technique is highly compiler sensitive. 

170 - DOTERM - Use of the DO loop index variable after normal loop 
termination is "undefined" by the ANSI Standard. The value 
assigned the variable can be quite surprising, depending 
upon compiler implementation. Using an assignment statement 
at the end of the loop v/ill normalize operation. 

If this use is detected, a secondary listing will be 

produced showing paths on which the index variable is used. 

/ 

(See "Flow of Control Path Tracing".)* 

180 “ ASNUSE - Local variables assi^qned values but never used 

are often keypunch errors or historical legacies. They 
may be cat.sed by errors in program logic. 


190 & 191 - UNINT - The use of an uninitialized local variable is 

caused by either keypunch errors or errors in program logic. 
The paths taken to the uninitialized use are available on a 
secondary report. (See "Flow of Control Path Tracing".)* 
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400 - 461 “ COMMOtl Block Misalignment 

COMMON Blocks wMcii arc not identical are usually 

* 

"errors waiting to happen". Maintenance is much less error- 

» 

prone where uniform COMMON structures are employed, The 
¥ 

efficiency of mixing modes and changing structures must be 
carefully v/eighed against difficulty in interpretation, 

Keypunch errors are particularly troublesome in COMMON. 

A mispunch can create a new labeled BLOCK totally detached 
from the rest of the system. A misspelled or transposed 
variable name may not be currently used; if referenced 
during modification, the programmer can expect a long and 
tedious search for the error, 

500 - 521 - Parameter List Misalignment 

Parameter alignment problems freguently lead to 
execution errors. They may be caused by keypunch errors or 
imprecise interface definition. 

Parameter count and type problems are obvious. 

Incompatible argument dimensions are either outright errors 
or invitations to malfunction, The use of differing 

dimensions should be approached with caution. ’ J 

600 - CYCALL - Cyclic calling sequences usually result in infinite ' \ 

loops unless recursive calling is explicitly supported. 1 

■ ■ 1 

Upon closing the cycle, the original entry return address | 

is destroyed,, This makes it impossibie to "get back" to the 

Initial routine. ; 

i 

i 

i 
1 . 
( 



A ppendix C 
Deck Set-Up 


It Is beyond the scope of this manual to present a detailed dis- 
cussion of how to use OCL to set up the execution of FACES. This task 
is left to the user, although examples are presented. 

A number of files must be allocated by the user. Some are direct 

(random) access files; most are sequential access files. Some files 
* 

are needed in only one phase; other files are needed in all phases of 
FACES execution. 


FACES uses eight files, which are listed below. Unless otherwise 
noted, each is a sequential file. 


2 

3 * 

4 * 

6 

8 

9 

10 

11 


FLAG; Flag File (FMS6: Fortran Message File) 

TABU Table File 

SCAT; Source Code Catalogue File 

PRNT; Print File (Output File) 

ANSI: ANSI Standards Function Names File 

CTRL: Control File 

SCIN: Source Code Input File 

RESW; Fortran Reserved Word File 


♦direct (random) access file 


These ^"iles are used during the following execution phases; 


Phase 1 . 

Phase 2 

Phase 3 

2 - FLAG 

2 - FLAG 

2 - FLAG 

3 - TABL 

3 - TABL 

3 - TABL 

4 - SCAT 

6 “ PRNT 

4 - SCAT 

6 - PRNT 

a - ANSI 

6 - PRNT 

9 - CTRL 

9 •• CTRL 

9 - CTRL 

10 - SCIN 

11 - RESW 



Significant File Sizes: 

FLAG “ 76 bytes, 10,000 records 
TABL - 400 bytes, 24,000 records 
SCAT - 80 bytes, 100,000 records 

FACES normally operates in four steps: 

1) Phase 1 (Fortran Front End) 

2) Phase 2 (Automatic Interrogation Routine) 

3) Sorting of FLAG File 

4) Phase 3 (Report Generator) 

Before Phase 1 can execute, the source code to be analyzed must 
reside in. the SCIN File, and the command cards used in Phase 1 must reside 
in the CTRL File. Allowable Command Cards for this phase are 


1 


4 


» 


a 
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INITIAL SYSTEM and 
ADD SOURCE 

During Phase 1 execution, flags are placed in the FLAG File, tables 
are produced and placed in the TABL File, the source code is catalogued 
and placed in the SCAT File, and all messages to be printed pass through 
the PRNT File. 

If a new software system is to be analyzed, the CTRL File must 
consist of 

INITIAL SYSTEM and 
ADD SOURCE 

’If new modules are to be added to the software system being analyzed, 
the CTRL File must consist of 
ADD SOURCE 

and the TABL and SCAT files must contain the liformation created on a 
previous run which depicts the software system _ being analyzed, (The 
TABL and SCAT files must be saved after a run if future analysis Is 
desired which bypasses Phase 1.) . 

The SCIN File may be discarded after Phase 1. 

Phase 2 uses two files used nowhere else in FACES. These files 
are ANSI and RESW. They are "read only" files. They are not needed if 
the user does not invoke queries 110 and 120 (search for ANSI Standards 
Function Names or Fortran Reserved Words used as user-defined names). 


C. 4 


The CTRL File may conLain only 
QUERY 

commands. 

During Phase 2 execution, flags are placed in the FLAG File, tables 
are read in from the TABL File or are produced and placed in the TABL 
File, all messages to be printed pass through the PRNT File, 'and ANSI and 
RESW are used as "read only" files for certain queries. 

( 

The sorting step involves ortiy the FLAG File. Each record in the 
file has the following format: 

FORMAT (5{2X,I5), 2X, 2A4, 3(2X,I5), 2X, 2A4) 

The sort is performed on the first seven integer fields, left- to- 
right, in ascending order. The sort is performed through JCL; FACES has 
no sorting capabilities. For further discussions, see the detailed 
description of the FLAG File. ‘ 

For Phase 3, the CTRL File consists of the command, 

REPORT 

This controls what information is to be printed during Phase 3. 

During Phase 3 execution, flags are read in from the sorted FLAG 
File, information is gleamed from the TABL and SCAT files, and everything 
to be printed passes through the PRNT File. 


/ 


I 


I 


I 
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Examples: 

) 

To analyze a software system completely for the first time, a deck 
might appear as 

* i 

OCL 


INITIAL SYSTEM 
ADD SOURCE 
OCL 


QUERY ALL 

QUERY ONLY = 190,191 
OCL 

. (Sort) 

REPORT FLAGGED 
OCL 


To add modules to a software system which has already been analyzed 
and whose TABL and SCAT Files have been saved, and needing only local 
analysis, a deck might appear as 


r 


c. 


JCL 

i 

t 

ADD SOURCE 
JCL 


QUERY LOCAL 
JCL 

. (Sort) 
REPORT FLAGGED 
JCL 


To perform a global analysis of a software system which already 
has been analyzed and whose TABL and SCAT Files have been saved, and 
needing a listing of all source code analyzed, a deck might appear as 

JCL 

■« , 

QUERY GLOBAL 
JCL 

. (Sort) 

REPORT ALL ,, 

JCL 


Note that Phase 1 has been bypassed. 



//HC3U^^9 jai (t 

. // A39••»•lMH1SV^C9U0CA9f StHS«UVCL«l 

//cam'll uec - — 

//sri^*.l• 00 osK*iii«o«.ti»f if«ois«t0f s#**SNt,ntt9i •¥o;.«S€4*cscooi 
//^ to^^ctl 00 0S<«*CiFLA».Uf«rT*0ISil.01 S9*iMeh*^ASSI« 

// Ac:« 1 7*,( xco.^on tOCft* UMecL«i».ii€Cf 

//^roi^crt 00 oski* cir*o«.«tiM ?*oi s«*oi s^«ci»€ii«r4ssi • 

// U€«l400f i 2<»C0CII«Xfl4CCA'««> «LAf CL«400«HLiiSI li*^00l 

//Ff?^fc:i 00 osi^-itsc Ar.uikt f•olSli•olsr•f weMt^ASsi » 

// s9Ace*«to, I ioocooii.xt*iKecfii«/ .LUcCL^iOtOLiisu^^toi 

//^roftfcci 00 STsaur«A 

//9T3ifC3l 00 • cm 9UC 

//^m:fcoi 00 • ici% MU 

//STS^Oun^ 00 STSOUT«A 

a;.iUC. FOt MC01M%9 WO^HI "" 

tiFZ37t 1S4 ULOCATEO TO SUAUS 

- UE^37| 112 ALiOCAlfO TO TfC^TOOl 

IEE217I 112 AtiOCATfO TO ETCITOQI 

1CF217I 112 ALLOCATED TO MO^EOOl 

IEE2J7I A7i ALLUCATEO TO f?C»r001 

IEE237I 411 ALLOCATEO TO EIC9E00I 

IEE21M 414 ALLOCATEO TO ETIOEOOl 

lEfilM 474 ALLOCATEO TO SVluOUM^ 

IcE1421 • STE9 has EIECUTEO - COHO CODE 0000 

IEE2ASI lAUDA - — AE^T 

1EE2IS1 VUL SEA AOS* CSCOCl. 

IEE2AM STS71210.TI 12404. A« 000. KOOl l44f.ELA« DASSED— * 

IEE2AS1 ¥0L SEA AOS- 222222. 

IEE2t>l STS75210.T1 12404. AVO00.AOO1 l44f.TA»L ~ - EASSED 

IEE2ASI ¥0L SEA MiS • 222222. 

IEf21SI SYS75210.T1 12 a04.A¥OC0.AO0I 1444. SCAT AASSED 

IEF2ASI ¥0L SEA AOS* 222222. 

!«Fl?i| SfJ^ /COANl / STAAT 7S210.I124 

1EF1741 STEA /(.OAhI / STOA 74210.1214 CAy 2A1A 21.S2SEC AAI 
//4QAA2 EIEC A«A*AHASE2»T|Af *S«AEC10A*10CA 

//SIEAlIA 00 0SA*AAAOA.yAIT*0ISA«0ISA«ISMA,AE€AK¥OL*S|AKSC00l 
wO OSA*lLf LA0.2IS**tCL0.AASSI 
//FTDlfoOl 00 OSA*LCTAaL»OISA*f OLO.AASSI 

//rfCVrjCl DO S¥S3UT»A 

/^FTCAFOM do 0SA*AAS UUA|T*01Sa.D1 SA«I SMA.MEAI •¥CL*UA*CSC001 

//ffOlAOll 00 • ctal file 

//FfllFCOl 00 OSA*AESw»yAXT*OlSK«DISA*ISNA.liEfAI»¥OL«SiA*CSC90l 
> //STS0JUA4 DO SYS0uT*A 

1EF214I ALLOC. FOA AC011449 40AH2 

IEF217I 1S4 allocated TO STEALIi 

1EF2J71 112 allocated TO FT02F0C1 

TEF2171 112 allocated TO FTOlFOOl 

1CF217I 471 ALLOCATEO TO FT04F001 

•IEF2I7I 1S4 ALLOCATED TO FTOAFOOI 

1EF217I 41S ALLOCATED TO FT04F001 

IEF217I 1S4 allocated TO ATIIrOOl ' 

TEF217I 474 allocated TO SYSUDONA 

- IEF142I - STEA has ClECOTEO - COAO COM 0000 

1EF2ISI tAAOA KEAT 

— 1EF24SI ¥0L SEA nOS* CSCOOl. - - - 

lEA2t4l SYS7S210.T1 12404.AYOOO.HOOI 1444.ALA4 AASSED 

IIF24SI — fOL SEA yys* 222222. 

IEF2ASI SYS7S210.T1 12404.A¥000«ll00ll44«.TAiL AASSED 

IEF2AST ¥0L SEA MOS* 222222. 

1EF2I5I AASl AEAT 

1EF2ASI ¥0L SEA MOS- CKOOl. 


IEF2ASI AES4 AEAT 

XCF2ASI ¥0L S|A 40S* CSCOOl. 

IEF171I STIA /00AN2 / STaAT 75210.121A 

1CF1741 STEA /C0AN2 / STCA 7S2K.1222 CAD OlIlM 4D.49SCC AA 

//TSOAT ElfC SOATD 


KISOAT IIEC A4n*IEAACOOO.AIOIOM*24A 
tlSYSOi^T DO SYS0UT*A 

I«S34Tl 14 OD 0S44nf .STSI.SaATLlA.DI SA«SMA 

VAnV.* ®‘4*LLALAA,#TS#«iOLD.DtUT€l 

//S14Y. SCLTOat 44 4S4.LL»L4l.4IS4*«»««.H4t&l.y4|f.DISA. 
## %» 4C«.«I^.|%44.14 ».Hc4A». 

## m »cv« 

.... ... .... ... .. 


iOD JS 



20D0D011 

40DOOD1D 

40000011 


Sample JCL 



omn 41.%«SCC MAlai 2 SUI LCS 


4(Sli M#T 

1C^2I)1 «Ol Sf« CSCOCU 

- - iffiMi sff> / 60 PH/ / $T 4 tr fs^io.iiia — 

ICfJ74| Sff^ / STO# 7»^IC.W22 UU Omn 41.%fSCC MAlai 2S4A LCS 

//Tso4r ftec sotro 

iis^ftr (tec It ft«ccj0t«e&i04*24ii lOi 

iiSfSvMf 00 StSCuT«a 

ItS^KUlB 00 OS44M£.S«SI.S3«TLIt.OI S^«SNI 4M 

— //&c«r. S04t Im Ow JS4«UftA4«0l5^«IX0f0tUfl*' 

//SQ«r. sctrour oo os4«it7ui.ois#*iRi€M.rAssi»uNif«omt 

// S»ACf(l4«llOO«2CI»ALSIIt 
// a: »•( fttCSH«Fi,L2 CCf 74.S14SUC-74I 
//SJ« f. sou kdCl 00 Min«OIS«.S»ACC»CCTLf I 111 
//S34T. SJir»4C2 00 umir-OlSKt S#ACC*ICfL»( 111 

//sou. SC4tMiO) 00 l7«0IS4»S^KL*4CrLtl III — 

//S JIT. sou *404 DO umf •0IS«»Sr4CC«CCfL»f 111 

//S04t.SfSt^ 00 • . 

1(12141 ALLOC. (OA 40011440 SUA I TSOAf 

- I(f2ill 4V1 AlLUCAKO to SfSOUf . ~ 

I((2I71 isi ALLOCAKO fO SOAfLIt 

lf(2J?l 1S2 -ALLOCATtO 10 SJATIIi - ■ ■ ^ 

l((2UI 112 ALlOCAfCO TJ S3AI0UI 

l((2S7| 112 ALLOCAfCO fO S3Af«iA0l 

lU2i7l li2 allocated TO SOAT4A02 

IE/2171 1S2 allocated TO SOATmaOI 

IEF2S71 112 ALLOCATEO TO S0ATmi04 

UA217I 414 ALLOCATEO 10 STSlIl — - — — 

1EE142I - STIA 4AS EIECuTCO - C OAO COOC 0000 

IEF24SI SfSl.SOATLIA AEAf 

IEF2ASI VCL SEA 40S* NASACl. ^ 

IEF2ASI SfS7S210. T1 12404. AtfOOO.OOOl I440.ILAD OELfTEO 

IU:«SI #04 SEA 4CS* 222222. 

Uftf ASI -- STS7S210.T1 t2404.AVOOO.MCOI144«.fLDl AASSEO — — 

1EE2ISI #J4 SEA MoS* 222222. 

IEI24SI SfS7S210.TI 124C4.A #000. AOOl 144f.ACC0000f OELfTEO 

1EI2AM #CL SEA iniS* 222222. 

1EF2A4I Sf S7S210.1 1 124O4.A#000.IK>0l |44f.AO*i00010 DEL ?(0 

UE24SI «UL SEA M)4* 222222. 

IEF2ASI • Sf S7S210.TI l2404.A#000.IK)0ll44f.i0 »0001l - OELfTfO— — — 

IEF2AS1 #U. SEA Hui • 222222. 

ltl2tSI STS IS2 1C. T 1 ;2404.A #000.0001 1444. A00000I2 t OELfTfO 

IEE#|SI #04 SEA 40S« 222222. 

IEF3711 STEA /SOAT / ST4AT 7S2I0.I222 

1(13741 STEA /SCAT / STOA 7S210.I223 C»U « 0HI«0S.S7SfC 4AIII 40A LCS 

//4CAM1 EtEC ADM»AHA^El»T|4(«l,AE410il-100A 

//STEALIO 00 0S4«|AA0A.Ulilf*0ISA,0ISA«ISMA,AEEA|,VOL»SEA*€SC001 
//ETD2E001 DO 0S4« LCf LDItOI SA-IOLO .Of Lf If I tUOl T«OI SA 
//MClrOCl 00 0SA«LiTA4L*JISA«l040.AASSI 

//AT04#Cdl 00 0Sli*ffSCAT,aiSA«4040.0€Lf Tfl - - 


IEE2171 ISI 
IEE2J7I 132 
IEE217I 112 
IEA217I 112 
1EF237I 132 
IE/2371 112 
IEF2171 112 
IEA237I 414 


IEF2ASI 

IEF2ASI 

IEF:. 5 I 


IEF24SI 

1EF2AM 

1EF2S4I 

UF24SI 

IEF2ASI 

IEF2AS1 

ltl2tSI 

IEF2ISI 


//FIC4FC0I 00 SfSOUl«A 

//FTOfFOCi 00'* CTAL AILI 

//STSiiovmA 00 stsout*a 
// 

IEA2341 ALLOC. FOA A0Cll44f «0AN1 
IEF237I 1S4 ALLOCATED TO STfALIO 

IEF21II 112 ALLOCATED TO FT02A001 

-IEF2371 112 ^allocated TO FTOJFOOl 

1EF237I 112 allocated TO FT04A001 

IEF2JII 473 ALLOCATEO TO AT04I001 

IEF237I 417 ALLOCATEO TO FTOOFOOl 

IEF217I 475 ALLOCATEO TO STSOOJM 


— IEAI42I - SffA 4AS flfCUTfO - COHO COOC 0000 . - 

1EF205I OANOA AfAf 

l|F2i5l— VOL SEA MOS* CSCXl. ■ ■■■ ■ 

IEF2ISI SfS7S2S0.ni2404.«#O00.U01144f.ALOl 0C4ITf0 

I|A2i5l #0L SEA MGS* 222222. - . . 

1IA2A51 STS7521C.TI 12004. AvOOO. hOOI l44f . TAOL AASSfO 

• - 1EA2A51 VOL SEA KOI* 222222. 

1EF2A5I SfS#52S0.TI 12404.AVOOC. HOOl 144f .SCAT OCLITEO 

UA2451 - VOL SEA liOS- 222222. 

IfFlTIt SriA /40A43 / ST4AT 75230.1221 

l(FS74t STEA /C0A»1 / SfOA 75290.1225 CAM CMtll 0A.02SCC lUIO 74« LCS #A 

• a««i . m » • » •• ••• 





- srf^ «AS MfCUTfD - C9H0 v30€ 9000 
S4M0« 

- S£4 HOS« CSCJCl. — — 

SrS7S^I0.n 12604..« V000.li001144f OCUlTfO 

vCc se« XOS* Z221ZZ. 

STS 74^10 .11 U604.tT00O«ll001144f.rAtL PAS SCO 

TUL SfA HuS* 222222. 

STS7S^}0.n UO04.IT00C. h001l449.se AT OlUffO 

• ¥0L SIA hCS« 222222 . 

STEP /OOPH) / SflfiT 74^30.1221 

STEP /GCPNl / ST3P 75230.1 22S CPU ONIM 0A.02SEC MAtM 
SYS75230.T1 1240^.KV 000. MOOl 144«. TAi.. QUifiO 

¥04 SEA AOS- 222222. - 

JOB /h001l44¥/ STAB? 75230.1124 

JOB 711001144 9/ Sr0P-’752J0.1225 CPU — ^UlU 14.20SEC 


BatTEAh AuTOhATEO CODE IWALUATIOII StSIEU IPACESI tOU - ftASlOh 


